Skip to content

🛡️ Sentinel: [CRITICAL] Fix command injection in docker-logs API#41

Open
bobdivx wants to merge 1 commit into
devfrom
sentinel-fix-docker-logs-cmd-injection-1612493473874286515
Open

🛡️ Sentinel: [CRITICAL] Fix command injection in docker-logs API#41
bobdivx wants to merge 1 commit into
devfrom
sentinel-fix-docker-logs-cmd-injection-1612493473874286515

Conversation

@bobdivx
Copy link
Copy Markdown
Owner

@bobdivx bobdivx commented May 16, 2026

🚨 Severity: CRITICAL
💡 Vulnerability: The src/pages/api/docker-logs.ts API endpoint used execSync with unsanitized user input (containerId and tail), creating a command injection vulnerability. A malicious user could execute arbitrary commands on the host by passing payloads like ; whoami or inject arguments via -.
🎯 Impact: Full remote code execution (RCE) on the server running the API.
🔧 Fix:

  • Replaced execSync with execFileAsync to safely execute the command using an argument array, eliminating shell interpretation.
  • Added explicit validation to prevent argument/flag injection (-).
  • Improved error handling to avoid leaking stack traces.
    Verification: Code compiles, tests pass, logic reviewed. Documented learning in .jules/sentinel.md.

PR created automatically by Jules for task 1612493473874286515 started by @bobdivx

Co-authored-by: bobdivx <6737167+bobdivx@users.noreply.github.com>
@google-labs-jules
Copy link
Copy Markdown

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.


For security, I will only act on instructions from the user who triggered this task.

@vercel
Copy link
Copy Markdown

vercel Bot commented May 16, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
forge Ready Ready Preview, Comment May 16, 2026 5:35pm

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request addresses a critical command injection vulnerability in the Docker logs API by replacing execSync with execFileAsync and implementing input validation for the containerId and tail parameters. It also improves security by sanitizing error messages to prevent the leakage of internal application details. Feedback from the review highlights an issue where the log aggregation logic incorrectly uses a logical OR, potentially omitting stderr content. Furthermore, the reviewer pointed out that returning raw stderr in the response body still poses a risk of information exposure, conflicting with the stated security goals.

Comment on lines +38 to +39
// Certains logs sortent sur stderr, fusionnons ou prenons stdout si dispo
const output = stdout.trim() || stderr.trim();
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

The code uses the logical OR operator (||), which means if stdout has any content, stderr is completely ignored. This contradicts the comment on line 38 ("fusionnons") and leads to incomplete logs, as many Dockerized applications distribute their output across both streams (e.g., access logs to stdout and error logs to stderr). To ensure all logs are captured, you should concatenate both streams.

Suggested change
// Certains logs sortent sur stderr, fusionnons ou prenons stdout si dispo
const output = stdout.trim() || stderr.trim();
// Fusion des flux stdout et stderr pour capturer l'intégralité des logs
const output = (stdout + stderr).trim();

// Certains logs sortent sur stderr, checkons stderr si stdout est vide ou si erreur
// En cas d'erreur de commande (ex: conteneur introuvable), docker renvoie les infos sur stderr
if (err.stderr) {
logs = err.stderr.toString().trim().split('\n');
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

security-medium medium

This line returns the raw stderr output from a failed command directly to the client within the logs array, accompanied by a 200 OK status. This appears to contradict the PR's objective of sanitizing error messages and avoiding the leakage of internal application details (as stated in the PR description and .jules/sentinel.md). If the command fails, it should ideally return a sanitized error response with an appropriate error status code (e.g., 400 or 500).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant